Proposition de quelques modifs mineures:

• désactiver les refresh, et refresh manuellement en one shot à la fin d'un process d'indexation. Il faudra penser à couper le refresh sur les index déjà existants si on part la dessus
• ne plus générer d'ID mais laisser ES affecter un ID à chaque élément. Si on affecte nous même un ID, ES doit checker pour chaque élément si cet identifiant existe déjà avant de pouvoir insérer l'élément, ce qui est assez couteux. Il faut cependant qu'on s'assure que lorsqu'on query on ne requête pas ce champ identifiant et plutot se baser sur le siret
• il m'a semblé qu'on avait un run de retry non batché en cas d'erreur 429 qui n'était pas nécessaire. La logique de wait & retry avec un temps exponentiel est me semble-t-il suffisante et évite de surcharger d'opérations ES
• lorsqu'on a plusieurs workers, le code attendait que tous les workers aient fini d'indexer avant de passer au batch suivant. Je propose de gérer un compteur de promesses en dehors du process d'indexation pour permettre que le nombre de workers affectés soit toujours utilisé à son maximum

Pour info, lors de mon dernier test sur un ES Scalingo starter 4GB, j'ai indexé les siret en 2h40 avec les paramètres suivants (contre environ 6h sur les derniers runs airflow, vers une gros ES 16gb redondé, mais qui a de la charge métier):

• INDEX_CHUNK_SIZE 10000
• TD_SIRENE_INDEX_MAX_CONCURRENT_REQUESTS 4
• TD_SIRENE_INDEX_MAX_HIGHWATERMARK 16384

Il m'a semblé contre productif de monter le highWaterMark dans mes tests, car la data est déjà bufferisée plus vite que ce que l'ES peut traiter, et donc augmenter la valeur ne faisait qu'augmenter la pression mémoire de la machine.